iT邦幫忙

2026 iThome 鐵人賽

DAY 21
0
AI Security

30 天認識 AI Security:從 LLM 攻擊到 AI 防禦系列 第 21

Day 21|Logging & Monitoring:AI 被攻擊時我們看得到嗎?

  • 分享至 

  • xImage
  •  

今天要介紹的 Logging & Monitoring(日誌紀錄與監控)主要是在說如果真的有人正在攻擊我們的 AI,我們知道嗎?那首先來說說 Logging,它其實也是傳統系統早就存在的技術,簡單來說就是把系統發生過的事情記錄下來,例如一般 Web Server 可能會記錄:

2026-09-20 10:21
User: 123
API: /api/orders
Status: 200

這樣當系統發生問題時開發者才有辦法回頭查看發生過甚麼事,到了 AI Application 其實也是一樣,只是除了傳統 API Log 我們可能還需要注意 AI 特有的行為,像是使用者是否大量觸發 Prompt Injection Detection、AI 呼叫了哪些 Tool、Tool Call 成功還是失敗、是否觸發 Input / Output Guardrail、是否出現大量被拒絕的請求等,這些紀錄都可以幫助我們了解 AI Application 到底發生了什麼事情。


簡單的 Logging

假設我們有一個 AI Agent 可以呼叫 Tool,可以先寫一個很簡單的 Log:

function logToolCall(userId, toolName) {
  console.log({
    time: new Date().toISOString(),
    userId,
    tool: toolName
  });
}

每次 AI 要使用 Tool 時:

logToolCall(userId, "refundOrder");
await refundOrder(orderId);

之後如果發現某個帳號突然產生大量退款就可以回頭查看到底發生了什麼,實際 Production 當然不會只靠 console.log(),通常會把 Log 集中保存,再交給 Logging / Monitoring 系統分析。

那 Monitoring 又是什麼?

有了 Log 之後我們已經可以知道系統曾經發生過哪些事情,但如果每天產生幾萬甚至幾百萬筆 Log,總不可能一直靠工程師自己打開來看,所以除了 Logging 之外通常還會搭配 Monitoring(監控),Monitoring 的概念就是持續觀察系統的狀態與紀錄,當出現異常情況時主動發現問題,例如平常一個使用者一天只會觸發幾次 Prompt Injection Detection,今天卻突然在十分鐘內觸發了 500 次,Monitoring 就可以把這種異常行為找出來,甚至設定 Alert 通知管理者,又或者某個 AI Agent 平常一天只會呼叫 20 次 refundOrder(),今天突然呼叫了 2000 次,也可能代表系統發生異常需要進一步調查。

所以平常如果只有 Logging,這 500 筆資料可能只是安靜地躺在 Log 裡,加入 Monitoring 之後就可以設定規則:

if (blockedRequests > 100) {
  sendAlert();
}

這樣就可以用 Logging 負責留下紀錄,Monitoring 則從紀錄中發現異常。

Log 不是記越多越好

可能有些人會想說乾脆把所有 Prompt、Response、User Data 全部記下來,但這反而可能產生另一個安全問題,假設使用者輸入了自己的信用卡號,Application 沒有把它輸出給其他人,卻完整寫進 Log,那 Log 本身就變成了一個存放敏感資料的地方,甚至 API Key、Access Token、Password 也可能不小心被記錄,所以 Log 也一樣只記錄真正需要的資訊,敏感資訊可以進行 Masking(遮蔽),例如:

Email: u***@example.com
Token: [REDACTED]

而 Log 本身也需要 Access Control,不能因為是 Log 就讓所有開發者都能隨便查看。

Monitoring 不只是抓攻擊者

Monitoring 還有另一個很重要的用途就是發現 AI 自己出了問題,例如突然出現 Tool Call 數量異常增加、Token 使用量突然暴增、Output Filtering 大量觸發、LLM Error Rate 上升、某個 Agent 不斷重複呼叫同一個 Tool 等,這些事情不一定代表有人正在攻擊,也可能是 Prompt 寫錯、程式 Bug、模型行為改變或系統設定出了問題,因此 Monitoring 不只是 Security 的問題,也能幫助我們觀察整個 AI Application 是否正常運作。


第三週我們串在一起看的話就是 Guardrails 是整體的安全控制概念;Input Validation 檢查進入模型的內容;Output Filtering 檢查模型產生的結果;Least Privilege 限制 AI 能做什麼;Human-in-the-loop 讓高風險操作需要人工確認;Secret Management 保護 API Key、Token 等敏感憑證;最後 Logging & Monitoring 則讓我們知道這些安全機制到底有沒有被觸發,以及系統正在發生什麼事情,最重要的就是建立多層防禦,讓其中一層失敗時後面還有其他安全機制,也就是前面一直提到的 Defense in Depth。

Logging & Monitoring 解決的是一個很現實的問題,安全機制做了很多但如果出事時完全沒有紀錄,我們甚至可能不知道自己曾經被攻擊,所以除了想辦法阻止攻擊也需要讓系統具有看得見發生什麼事的能力,到這裡第三週的防禦篇也告一段落,下一週我們就把前面學到的 Prompt Injection、Tool、權限與 Guardrails 全部放進更完整的 AI 系統中。

下一篇:Day 22|AI Agent:當 AI 從回答問題變成自己完成任務


上一篇
Day 20|Secret Management:API Key 到底應該放在哪裡?
下一篇
Day 22|AI Agent:當 AI 從回答問題變成自己完成任務
系列文
30 天認識 AI Security:從 LLM 攻擊到 AI 防禦24
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言